Collection docs #27902
Collection docs #27902
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
This all looks good to me, and I'm on board with it, but documenting that we'll never to a small vector optimization probably wants some more visibility, so: cc @rust-lang/libs |
alexcrichton
added
I-needs-decision
| /// uninitialized elements. | ||
| /// | ||
| /// Vec will never perform a "small optimization" where elements are actually | ||
| /// stored on the stack for two reasons: |
There was a problem hiding this comment.
on the stack is kind of the wrong terminology. The vec is just a value, and it can live anywhere, so "inline" is more correct.
|
☔ The latest upstream changes (presumably #27998) made this pull request unmergeable. Please resolve the merge conflicts. |
| /// overriding their defaults may change the behavior. | ||
| /// | ||
| /// Most fundamentally, Vec is and always will be a (pointer, capacity, length) | ||
| /// triplet. No more, no less. The order of these fields is completely |
There was a problem hiding this comment.
Will this also be true if we ever add a allocator type paramter? Possible designs I've seen for this might add an additional field to the type:
struct Vec<T, A: Allocator=Heap> {
data: *mut T,
len: usize,
capacity: usize,
allocator: A::HandleData,
}There was a problem hiding this comment.
Right above this:
Note that these guarantees refer to an unqualified
Vec<T>.
If additional type parameters are added (e.g. to support custom allocators),
overriding their defaults may change the behavior.
There was a problem hiding this comment.
(allocator would be a ZST by default, so its only impact could be ordering, which is already unspecified)
|
As a additional data point against allowing smallvector optimizations: My owning-ref crate currently assumes that the backing storage of a |
|
The libs team discussed this during triage today and the conclusion was to r+ with a rebase. |
|
@gankro are you going to rebase this, or do you want a hand? I know you've been really busy. |
|
@steveklabnik please do! |
|
Superseded by #28797 |
…lexcrichton This is a rebase of rust-lang#27902, since @gankro is busy ❤️
…lexcrichton This is a rebase of rust-lang#27902, since @gankro is busy ❤️
Two commits:
Clarify what Vec does and doesn't precisely guarantee. People are already relying on this stuff, so we might as well call it a day and specify it. This commit deserves serious scutiny.
Remove references to deprecated collections from the top level collections docs.